Dev/Permanent Takedown Attack Defender
Donate
This is a proposal to defend a permanent takedown attack. A mechanism to securely download project metadata, which includes censor resistance, defeating rollback and infinite freeze attacks.
Summary[edit]
This is a proposal to defend a Permanent Takedown Attack (PTA). A mechanism to securely download project metadata, which includes censor resistance, defeating rollback and infinite freeze attacks.
Both, TUF (The Update Framework) [1] [2] and PTAD (Permanent Takedown Attack Defender), do not require software to be running on a server and can be run on any (free) web space. [3]
Definitions[edit]
Definition by this page:
Project metadata. Is defined as version information, news, update information, project homepage and so on.
Definition by this page:
Permanent takedown attack. An attacker takes down a mirror by taking over the domain or by taking down the server using DoS [4] attack, cracking down the server with malware or by pressuring humans (the server administrator).
Quote: TUF: Attacks and Weaknesses [5]:
Rollback attacks. An attacker presents a software update system with older files than those the client has already seen, causing the client to use files older than those the client knows about.
Quote: TUF: Attacks and Weaknesses [5]:
Indefinite freeze attacks. An attacker continues to present a software update system with the same files the client has already seen. The result is that the client does not know that new files are available.
Motivation[edit]
What happens if an adversary ever manages to ban project websites such as Tails or Kicksecure? Boum.org domain and server lost, Kicksecure kicked from kicksecure.com server not getting any other hosting platform.
The project admins will lose the ability to inform their users about critical security updates and communications break down. Users will no longer be able to visit the original homepage, which could even get replaced with a malicious version.
It would take some time to reorganize hosting, move to censor resistant hosting and to inform the existing user base.
Discussion[edit]
Using a single server, i.e. single domain/server for project metadata is recommended against, as it introduces a single point of failure. When the server goes offline, project metadata can no longer be distributed. The server could also serve either due to a bug or by malicious intent a gpg signed, but outdated project metadata.
To prevent disclosing which software is fetching project metadata, the request must go through Tor. Identity correlation through circuit sharing must be circumvented by using a separate circuit for project metadata fetches.
GPG signing of project metadata is a must, since it is independent from SSL certificate authorities.
The public key of the signer must be included into the software project at build time. Distributed trust could be implemented by using X signing keys and defining, that project metadata has to be signed by at least Y of X signers to be accepted as valid.
Apparently, there is not any distributed censor resistant data storage available over Tor. Freenet is a distributed censor resistant data storage, which can unfortunately not be accessed over Tor. [6] Otherwise Freenet could be well suited for this purpose. This is likely not going to change anytime soon. [7]
Had a constructive discussion with GNUnet devs. Will wait for the next stable announcement. [8]
Implementation[edit]
There are web services run by different organizations, which allow (free) web hosting, which can be used for project metadata. Examples are github pages, sourceforge file release system and free onion hosting services.
Below is an example, how a project metadata file could look like.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 projectversion: 9 metadataversion: 536 validuntil: 1369159330 homepage: https://www.project.com news: No important news. mirror 1: httsp://project.sourceforge.net/project_news.asc mirror 2: http://onion.onion/project_news.asc -----BEGIN PGP SIGNATURE----- xxxSIGNATURExxx -----END PGP SIGNATURE-----
Such a project metadata file is supposed to be initially copied into the project's binary distribution at build time. The purpose is to initially equip the metadata fetcher with a list of mirrors.
From all available mirrors, the metadata fetcher uses all [9] mirrors at each run time to download the current project metadata. If metadata mirrors are modified or expanded, the updated file will possibly be stored persistently and overrule the metadata file which was included at build time.
The projectversion variable contains the version of the project and can be anything. The homepage variable contains the latest homepage of the project. It can be useful to inform users about the new homepage in case the old one has been taken down. The news variable contains a plain text string. Most of the times it shouldn't contain anything and should only be used to inform users about urgent things, such as when a takedown attack is in place.
The metadataversion variable is a consecutive number, i.e. after 536 follow 537. Each update of the metadata file increases that number. The client may not accept lower metadata version numbers, than the client already knows about. This should defeat rollback attacks.
Defeating indefinite freeze attacks is technically a bit more difficult. Each metadata fetch against a different mirror has to go through its own Tor circuit. Going through its own Tor circuit, most times a different Tor exit will be used (and connections to onion services are stream isolated so or so). This will result in using different ISP's to connect to the metadata mirror and as long as not all Tor exit relays or all Tor exit relays's ISPs or all metadata mirrors are compromised, no indefinite freeze attack can be successfully mounted. When fetching from onion services, there are no ISP's involved, who could tamper with the metadata.
The validuntil variable represents how long the file is valid, until the mirror is considered outdated. The number represents the time in unixtime [10]. If a mirror is considered outdated, a new mirror will be tried.
Distributed trust for the signers has not yet been considered. The signers gpg key is fully trusted. To implement this, one could look into the TUF project, since the TUF project already contains code to define a threshold of signers.
Specifically for Kicksecure, systemcheck and the Kicksecure News Format could be extended.
See Also[edit]
- Dev/project-news
- apt-revoker Check for Revocation Certificates before running apt
- package manager update security on/off switch
- ticket: https://phabricator.whonix.org/T114
- https://forums.whonix.org/t/permanent-takedown-ideas/8890/1
Footnotes[edit]
- ↑
https://theupdateframework.io/
- ↑
https://github.com/theupdateframework/tuf
- ↑
https://github.com/theupdateframework/tuf/issues/78
- ↑
https://en.wikipedia.org/wiki/Denial-of-service_attack
- ↑ 5.0 5.1
https://theupdateframework.io/security/
- ↑ Freenet could be accessed over Tor, by tunneling UDP over Tor using a VPN. This is too unsuitable for most users to be considered as a workaround. Most VPNs cost money, VPN over Tor is a hack alone and there are not as many VPN nodes as Tor exits, are there?
- ↑
Broken link:
https://emu.freenetproject.org/pipermail/devl/2016-December/039447.html - ↑
https://lists.gnu.org/archive/html/gnunet-developers/2016-12/msg00033.html
- ↑ Or if load balancing is required, using multiple and random mirrors.
- ↑
https://en.wikipedia.org/wiki/Unix_time
A secure by default operating system with the latest security research in place.
At
Kicksecure we value freedom and trust, supporting Open Source and Freedom Software
2012-
2024 ENCRYPTED SUPPORT LP
We believe security software like Kicksecure needs to remain Open Source and independent. Would you help sustain and grow the project? Learn more about our 12 year success story and maybe DONATE!